与 Python 之父聊天：更快的 Python！

注：在今年5月的 Python 语言峰会上，Guido van Rossum 作了一场《Making CPython Faster》的分享，宣告他加入了激动人心的“香农计划”，旨在 4 年内提升 Python 性能至 5 倍。近日，Guido 上了一档英文播客节目（时长 30 分钟），谈论了他正在做的与高性能相关的工作，解答了几个问题。播客作者整理了一份内容纪要，本文是对该纪要的翻译。注：文末有音频及文稿下载

1、为什么你会对研究 Python 的性能感兴趣？

Guido：在某种意义上，它对我来说是一个相对舒服的话题，因为这意味着与 Python 的核心打交道，而我对这方面还算熟悉。当我在微软工作时，我曾短暂地关注过 Azure，但我意识到我在谷歌或 Dropbox 时就不喜欢这类工作。然后我关注了机器学习，但这需要花很多时间来做一些与 Python 无关的事情，甚至它与 Python 相关的部分就很少。

2、Mark Shannon 关于 Python 性能的那些想法有何不同，怎么能说服你去实现它们的呢？

Guido：我喜欢他思考问题的方式。大多数其它聚焦于 Python 性能的方法，如 PyPy 和 Cinder，并不适用于所有的使用场景，因为它们不能向后兼容扩展模块。Mark 具有 CPython 开发者的视角和经验，并且有一种可行的方法来维持向后兼容性，这是最难解决的问题。Python 的字节码解释器经常要在小版本之间（例如 3.8→3.9）进行修改，原因有很多，比如新的操作码，所以修改它是一种相对安全的方案。

3、你能给我们解释一下 Python 解释器的分层执行的概念么？

Guido：当执行一个程序时，你不知道它会在运行了几分之一毫秒后崩溃，还是会持续运行三周时间。因为对于同一份代码，在第一种情况下，它可能触发了一个 bug。如果运行程序需要三周时间，也许提前半小时优化所有待运行的代码是有意义的。

但很明显，特别是在像 Python 这样的动态语言中，我们尽可能多地做，而不要求用户告诉我们他们到底需要怎么做，你只是想尽快开始执行代码。所以，如果有一个小脚本，或者一个大程序，它碰巧执行失败了或者因为某些原因提前退出了，你就不用花费时间去优化全部的代码了。

所以，我们要做的就是保持字节码编译器的简单化，以便能尽快地开始执行代码。如果有某些函数被多次执行，那么我们就称其为 hot 函数。“hot”存在多种定义。在某些情况下，如果一个函数被调用超过一次，或者超过两次，或者超过 10 次，那么它被定义成一个热门函数。而在其它保守的情况下，你可能说“只有被调用 1000 次才算 hot”。

然后，当参数的类型是某些特定类型时，专门化的自适应编译器（PEP-659 Specializing Adaptive Compiler）会尝试用更快的字节码来替换某些字节码。一个简单的假想的例子是 Python 中的加号运算符，它可以令很多对象相加，比如整数、字符串、列表，甚至元组。但是，你不能将整数与字符串相加。

因此，优化的方法就是提供一个单独的“两个整数相加”的字节码，它是一个对用户隐藏的第二层字节码。（“优化”通常被称为加速 quickening，但一般在我们的语境中，我们称之为专门化 specializing）。这个操作码假设它的两个参数都是真正的 Python 整型对象，直接读取这些对象的值，并在机器寄存器中将这些值相加，最后将结果推回堆栈。

两个整数相加的操作仍然需要对参数进行类型检查。因此，它不是完全不受约束的，但这种类型检查相比于完全泛化的面向对象的加号操作，前者在实现上要快得多。

最后，有可能一个函数被整型参数调用了数百万次，然后突然一小段代码用浮点型参数调用它，或者出现更糟的情况。此时，解释器会直接执行原始的字节码。这是一个重要的部分，让你始终能得到完整的 Python 语义。

注：“香农计划”的最终目标是将解释器的执行过程分层，并对不同层做出定制的优化。详情请查阅 Github 项目的介绍（https://github.com/markshannon/faster-cpython/blob/master/tiers.md）。

4、通常你会在谈 JIT（Just-In-Time）编译器时听到这些技术，但官方 Python 现在还没有实现。

Guido：即时编译的方案有一大堆我们想要避免的情感包袱。比如，我们不清楚到底编译什么，以及什么时候编译。在程序开始执行之前，解释器将源代码编译成字节码，然后，再将字节码转换为专门的字节码。这意味着，所有的事情都在运行时的某个时刻发生，那么，哪个部分是所谓的即时（Just-In-Time）呢？

另外，人们通常认为 JIT 会自动地使所有代码变得更好。不幸的是，你通常无法真正地预测代码的性能。由于有现代的 CPU 和它们神奇的分支预测，我们已经拥有了足够的性能。例如，我们以一种本认为能够明显减少内存访问次数的方式，编写了一份代码。但是，当对它进行基准测试时，我们发现它的运行速度与旧的未优化代码一样快，因为 CPU 在没有我们任何帮助的情况下，计算出了优化的访问模式。我希望我知道现代 CPU 在分支预测和内联缓存方面做了什么，因为这就像是魔法一般。

完整内容

以上就是播客节目纪要的翻译。更多完整的对话内容，以及对话音频，我已保存好了。你如果感兴趣的话，请在 Python开发者 公众号里发送数字“python faster ”，即可获取下载链接。

作者：Software at Scale

译者：豌豆花下猫@Python猫

原文：

https://www.softwareatscale.dev/p/software-at-scale-34-faster-python

- EOF -

推荐阅读  点击标题可跳转

觉得本文对你有帮助？请分享给更多人

推荐关注「Python开发者」，提升Python技能

点赞和在看就是最大的支持❤️